home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19990422-19990725 / 000140_news@watsun.cc.columbia.edu _Fri Jun 11 09:55:38 1999.msg < prev    next >
Internet Message Format  |  2020-01-01  |  6KB

  1. Return-Path: <news@watsun.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id JAA23156
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 11 Jun 1999 09:55:38 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id JAA02585
  7.     for kermit.misc@watsun.cc.columbia.edu; Fri, 11 Jun 1999 09:42:59 -0400 (EDT)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: peter@baileynm.com (Peter da Silva)
  10. Subject: Re: ISO VT320 emulator with key-bindings for Oracle Forms
  11. Date: 11 Jun 1999 13:27:33 GMT
  12. Organization: Bailey Network Management
  13. Message-ID: <7jr2s5$4sc@web.nmti.com>
  14. To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <7johsh$egs$1@newsmaster.cc.columbia.edu>,
  17. Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
  18. >tputs() can be void or int.  The third argument of tputs(), which is a pointer
  19. >to a function to put a character, can be void, int, or char.  The argument
  20. >to that function can be void or char.  Thus there are at least 2 x 3 x 2 = 12
  21. >combinations that must be accounted for in any portable code that uses tputs().
  22.  
  23. Luckily you don't need to account for it by writing 12 versions of the code.
  24. I normally encapsulate tputs itself into a routine (the name I usually use
  25. is "outs"), and since C specifies that (char) promotes to (int) in fuction
  26. call and return, that leaves you with two versions of the call to tputs
  27. and two versions of the output function, in one place in the code.
  28.  
  29. >: > c. Dependent on buggy and/or incomplete databases;
  30.  
  31. >: That's something the end-user can fix.
  32.  
  33. >If the end-user knows how to.  This is a rather obscure and dying art; one
  34. >does not rely on end-users to have mastery of it.  In these times, end-users
  35. >expect software to "just work".
  36.  
  37. End users who aren't using ANSI X3.64 compatible terminals in 1999 are already
  38. at the extreme end of the envelope.
  39.  
  40. >: > d. Offer only an incomplete and sketchy model of any real terminal,
  41. >: >    not even close to sufficient for defining an accurate emulation;
  42.  
  43. >: My vt100 emulator, which used raw termlib, did a better job of vt100
  44. >: emulation than most commercial packages.  It didn't try and provide
  45. >: perfect visuals: double-wide and double-high letters, for example, were
  46. >: simply not addressed. But it passed the vt100 torture test.
  47.  
  48. >Then it didn't run strictly from termcap/terminfo information; otherwise, it
  49. >wouldn't have been a vt100 emulator, it would have been an emulator of every
  50. >terminal that had an entry in the database, right?
  51.  
  52. No, it was a vt100 emulator that emulated the vt100 on every terminal in the
  53. database.
  54.  
  55. > The database only encodes
  56. >certain information about a terminal, not all the information needed to make
  57. >a fully functional emulator.  Such items as report requests and responses,
  58. >forms-filling, and blockmode spring to mind.
  59.  
  60. Luckily I haven't ever had to deal with that on a vt100. Virtually all the
  61. software I've ever run into that used block mode used it on a Televideo,
  62. a Televideo-compatible, or a Uniscope.
  63.  
  64. But there's nothing inherently more difficult about dealing with block
  65. mode than dealing with any of the other behaviour termcap doesn't specify.
  66.  
  67. >: > e. Notorious for refusing to work due to library version mismatches;
  68. >: > f. Sometimes not available at all.
  69.  
  70. >: That's an easy fix. Same solution as B.
  71.  
  72. >It's easy if you understand cryptic messages about shared libraries, and
  73. >are familiar with the politics regarding curses vs ncurses, libc vs glibc,
  74. >competing numbering schemes, etc, and what to do about them.
  75.  
  76. I haven't run into that, but then I haven't writen code for Linux.
  77.  
  78. >: >And that in any case, this does not solve the original problem:
  79.  
  80. >: >  How do I map Shift-Alt-F7 to such-and-such a function?
  81.  
  82. >: >The answer will still be: "you can't, because the software has no way of
  83. >: >knowing that you pressed Shift-Alt-F7".
  84.  
  85. >: With a keyboard mapping file that maps escape sequences to symbols that
  86. >: the user's interested in.
  87.  
  88. >If xmodmap recognizes your keyboard and can see Shift-Alt-F7 as distinct from
  89. >other key combinations, then yes, but only for xterm.  A separate solution is
  90. >required for the console.  Remote (non-X) sessions haven't a prayer.
  91.  
  92. Where did I say anything about xmodmap? I'm simply saying that a properly
  93. written terminal emulator can run on UNIX and provide the functionality
  94. required. That there isn't one that you know of is because there isn't a great
  95. need for one, not that one's hard to write. As I said, I wrote one that ran
  96. on Xenix-286, Solaris, and System V back in the late '80s. It was a port from
  97. a DOS program I'd previously written, and I didn't find the porting
  98. particularly difficult. Certainly dealing with termcap was a lot less hassle
  99. than dealing with PC serial ports.
  100.  
  101. >It is hard to explain this to people who expect UNIX to be like Windows.
  102. >While it might be possible to write a true terminal emulator for a specific
  103. >UNIX variety on specific hardware that runs only in an X window (and in fact
  104. >there are numerous examples -- xterm, Xfree86 xterm, the xterm versions from
  105. >HP, IBM, and other companies that emulate their own proprietary terminal
  106. >types), it is not possible in the general case, due to differences in hardware
  107. >(e.g. different keyboards), windowing systems (in the X environment), screen
  108. >drivers (in the console environment), APIs, and access methods.
  109.  
  110. That's just plain not true. Curses provides all the functionality you need
  111. to write one that is portable to multiple UNIX systems and runs under multiple
  112. terminal types. Yes, you do need to write your own keyboard mapping code, but
  113. then you already have to do that to write a terminal emulator under Windows
  114. that runs on internationalized versions.
  115.  
  116. I've done it myself, and there were several companies back in the '80s who had
  117. commercial products that ran on a wide variety of UNIX platforms... I used
  118. to have half a dozen boxes back in the computer room but they seem to have been
  119. flushed in one of the spring cleanings. You can do as good a job of vt100
  120. emulation on a UNIX system as you can on a PC.
  121.  
  122. -- 
  123. In hoc signo hack, Peter da Silva <peter@baileynm.com>
  124.  `-_-'   Ar rug t∩┐╜ barr∩┐╜g ar do mhact∩┐╜re inniu? 
  125.   'U`    "Be vewy vewy quiet...I'm hunting Jedi." -- Darth Fudd
  126.